Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@packages/setupWizard/src/azuredevops.ts`:
- Around line 24-37: The URL input currently allows plain http and doesn't
persist a trimmed value; update the input validation and assignment around the
prompt (the call to input(...) that sets config.url) to require HTTPS by default
by changing the validate function to reject non-https schemes, trim the value
before validation/assignment, and only allow http if the user explicitly
confirms an insecure choice (e.g., an extra confirmation prompt when v
startsWith 'http://'); finally assign the trimmed URL to config.url instead of
the raw input.

In `@packages/setupWizard/src/bitbucket.ts`:
- Around line 161-174: The URL input validation currently allows http and stores
the raw value; update the validate callback passed to input(...) to require
HTTPS only (reject if it doesn't start with https://) and normalize the saved
value by trimming whitespace before assigning to config.url (use the trimmed url
variable). If you want to support insecure HTTP as an opt-in, add an explicit
flag (e.g., allowInsecure) or a separate prompt rather than silently accepting
http in the validate function; locate the validate lambda and the assignment to
config.url to make these changes.

In `@packages/setupWizard/src/genericGit.ts`:
- Around line 6-22: The prompt validates trimmed input but assigns the raw
untrimmed value to config.url, so normalize the URL by trimming before storing;
update the code around the input(...) call and the
GenericGitHostConnectionConfig creation (the url assignment in config) to use a
trimmed value (e.g., const url = (await input(...)).trim() or const trimmed =
url.trim(); config.url = trimmed) so whitespace is removed before writing the
config.

In `@packages/setupWizard/src/gerrit.ts`:
- Around line 7-23: The Gerrit URL input is validated using trim() but the code
stores the raw url, allowing leading/trailing whitespace to persist; update the
input handling so that the captured variable (url from input()) is normalized
(call .trim()) before constructing the GerritConnectionConfig object (the config
variable of type GerritConnectionConfig) so the saved url is clean and
connection resolution won’t break; ensure any further uses of url reference the
normalized value rather than the original raw input.

In `@packages/setupWizard/src/gitea.ts`:
- Around line 10-25: The Gitea URL prompt currently accepts http:// and doesn't
trim input; update the input validation and post-processing so only https:// is
allowed by default: in the input(...) validator (the call that returns `url`)
require /^https:\/\// or, if you must allow http, add an explicit additional
confirmation step before accepting http URLs, and always use the trimmed value
(e.g., v.trim()) when assigning to config.url; finally assign the trimmed URL to
config.url (replace the current config.url = url conditional) so stored URLs are
normalized and HTTPS is enforced unless the user explicitly confirms insecure
HTTP.

In `@packages/setupWizard/src/github.ts`:
- Around line 43-44: Wrap the network call and JSON parsing in a try-catch
around the fetch(url, { headers }) and await res.json() calls so network errors
or malformed JSON are handled; on catch, log the error and return an empty list
or signal failure so the wizard falls back to literal entry instead of crashing;
update the code that uses the parsed `data` (the `data` variable and any
handling of `data.items`) to handle the fallback/empty case safely.

In `@packages/setupWizard/src/gitlab.ts`:
- Line 41: Wrap the network call that currently does "const res = await
fetch(url, { headers })" in a try-catch inside the same function so
network-level failures (DNS, timeouts, connection refused) are caught before the
subsequent "!res.ok" logic; in the catch block return or throw a controlled
error (or call the existing error handling/logging path) including context (URL
and token scope) so the wizard doesn't crash, and keep the existing res.ok
handling for HTTP-level errors.

In `@packages/setupWizard/src/index.ts`:
- Around line 25-27: The DOCKER_COMPOSE_BRANCH constant is pointed at a feature
branch; update DOCKER_COMPOSE_BRANCH to 'main' so DOCKER_COMPOSE_URL fetches the
canonical docker-compose.yml from the main branch (ensure the symbol
DOCKER_COMPOSE_BRANCH is changed and that DOCKER_COMPOSE_URL continues to build
from it).
- Around line 211-224: The current override generation mounts all
localRepoHostPaths to the same container path (/repos), causing shadowing;
change the mount creation in the block that builds overrideYaml (where
uniquePaths is used) to produce indexed container paths like /repos/0, /repos/1,
etc., and then update collectLocalReposConfig() to accept or build a mapping
from each host path to its assigned indexed container path so connection URIs
are generated as file:///repos/0/... (or file:///repos/{index}/{rel}) instead of
the current hardcoded file:///repos/*; ensure the same deduplicated order is
used for both the overrideYaml generation and the mapping passed into
collectLocalReposConfig() so paths and indices align.

In `@packages/setupWizard/src/localRepos.ts`:
- Around line 84-96: The path validator (the validate arrow function calling
expandHostPath, existsSync and statSync) can throw from statSync (or existsSync)
and must be guarded; wrap the filesystem checks in a try/catch so any thrown
errors return a validation message rather than crashing the wizard—use
expandHostPath(v) to get resolved, then in a try block check
existsSync(resolved) and statSync(resolved).isDirectory(), and in the catch
return a descriptive string like `Unable to validate path: <error message>` (or
a generic "Unable to access path") to surface permission/race errors to the
user.
- Around line 111-140: The relative-path handling is Windows-unsafe: change uses
of relative(hostPath, p)/rel that assume POSIX separators; compute a normalized
POSIX-rel path (e.g., call relative(hostPath, repoPath) then replace backslashes
with forward slashes or use path.posix operations) and use that normalized value
when computing allAtDepthOne (check !normalized.includes('/')) and when building
the file URL in connections (use the normalized rel inside
file:///repos/${...}); update references in this block (repos, hostPath,
relative, allAtDepthOne, connections, rel, GenericGitHostConnectionConfig) so
all path checks and generated URLs use the forward-slash normalized path.

In `@packages/setupWizard/src/utils.ts`:
- Around line 27-29: toEnvKey currently only replaces hyphens and can produce
invalid env var names for inputs with spaces, dots, slashes or leading digits;
update the toEnvKey function to fully sanitize the connectionName by replacing
all non-alphanumeric characters with underscores, converting to upper case,
collapsing consecutive underscores, trimming leading/trailing underscores, and
if the resulting key starts with a digit prefix it with an underscore, then
append the uppercased suffix separated by a single underscore; reference the
toEnvKey(connectionName: string, suffix: string) function and apply the
described normalization steps so generated env keys are valid POSIX-style
environment variable names.

In `@packages/setupWizard/tsconfig.json`:
- Line 12: Update the TypeScript configuration so builds fail to emit when there
are type errors by changing the tsconfig.json setting "noEmitOnError" from false
to true; locate the "noEmitOnError" key in tsconfig.json and set it to true to
prevent publishing or running a dist build that contains type-check failures.

---

Nitpick comments:
In `@packages/setupWizard/src/models.ts`:
- Around line 15-25: PROVIDER_ENV_KEYS is missing Google Vertex-specific keys so
GOOGLE_VERTEX_PROJECT, GOOGLE_VERTEX_REGION, and GOOGLE_APPLICATION_CREDENTIALS
are being miscategorized; update PROVIDER_ENV_KEYS to include those three keys
(referencing the constant PROVIDER_ENV_KEYS in
packages/setupWizard/src/models.ts) or alternatively add a distinct set used by
the filtering logic in index.ts so the index.ts filtering routine treats these
keys as AI provider credentials rather than code host credentials; modify the
constant or the filter to include the three Google Vertex env var names and
ensure the index.ts code that computes AI provider vs code host sections uses
that updated set.